In the control of input/output devices, a program software will issue commands that will initiate requested actions in the input/output device or adapter. The command may be a request to start, stop or cancel some action or event. The start command, for example, may be an explicit start command or an implied start through the loading of a value into a device register.
When a command is issued, the program software does not always know exactly the state of the input/output device. It can read status to determine the device state. However, if external asynchronous events can alter the state of the input/output device, then the status may simply reflect the state only at the instance the status was sent. It does not indicate that the state at a future point in time when the command is to be issued. Thus, there exists some uncertainty of the device when the command is issued.
One way to circumvent the problem of uncertainty is to design the input/output device adapter to include intelligence having the capability to determine if current conditions permit the acceptance and execution of the specific command that is issued. This determination and start of execution must occur at a single atomic point in time. The problem now is to determine if the command was accepted and execution started or was the command rejected and the operation aborted. Reading status in a subsequent operation will tell the state at that point in time, but will be at some later point in the operation of the system.
This problem was previously addressed in the IBM System 360 using an architecture providing a feedback in the form of condition codes to inform the software of the success or failure of a StartI/O command. The condition codes reflected the state of the adapter following issuing of the command. The condition codes were then generated by the communications channel and did not reflect the action taken by the actual input/output device.
The IBM System 370-XA architecture defined another command "StoreSubchannel and TestSubchannel". These commands read subchannel status and placed the status in main storage. The TestSubchannel command also reset the subchannel in any pending interrupts. However, neither command initiated an operation or transaction within the channel.
In most systems today the software program executing in the system processor has a very tight coupling with the input/output adapter. In general, the input/output adapters are mapped into the memory address space of the processor (i.e., memory mapped I/O). Thus the LOAD and STORE instruction are used to reference both memory and the I/O adapters. The affective address generated by the execution of the LOAD and STORE instruction determines what facility is referenced (memory, or which adapter or even which register within the adapter). When the LOAD or STORE instruction is directed to an I/O adapter, data is transferred between the general purpose registers of the processor and the selected registers with the adapter. This form of I/O control is generally called Program I/O or PIO.
IBM Technical Disclosure Bulletin, Vol. 15, No. 4, September, 1972, pages 1232-33, entitled "Channel Initiated Subsystem Diagnostics" discloses a typical and traditional method of dispatching channel commands. In this disclosure diagnostic test commands are dispatched over a channel and at the end of the designated test, a status is provided.
IBM Technical Disclosure Bulletin, Vol. 30, No. 11, April, 1988, pages 28-31, entitled "SPD I/O Bus Operation Testing Protocol" also discloses a protocol for initiating tests. After a bus operation request message is sent and bus operation function block is read, a status will be returned to the host processor providing an initial status of the device to be tested.